Subject: Reply to Jeff's concerns

From: "Chung-Huy Chen (254-4827 T/L 444)" <[email-masked]>
Date: Wed, 2 Feb 94 09:37:56 EST

Jeff,

You raised two questions in your last note:
  1) How can data conversion fit into the mapped-conversation type?
  2) How can my proposed solution to the Receive call be done
     without impacting the state tables?

                    * * *
To the first problem, I think you were concerned about how data
conversion can be added to the LU and work with the buffering
mechanism (in LU's term, LL-processing) under the mapped-conversation
type.  If we can view data conversion and buffering mechanism as
two logical tasks, here is how I see a mapped conversation works:
   i) If no map name has been set for the conversation,
      the LU does only buffering just as today.
  ii) If a map name has been associated with the conversation,
      the LU does both.

Note that even if data conversion is a conversation type all by
itself like you suggested, the LU will still have to do both
conversion and buffering since "logical record" has a significant
meaning to the LU.

With this solution, the LU will do more than what it does today.
But the program need not be aware of this difference since the
meaning of a mapped conversation is just that the LU will do all
necessary processing on the data for the program.

                    * * *
My proposed solution to the Receive problem was:
:  When the CRM receives data with a map name, the Receive behaves
:  as follows:
:     If a deallocation indication has also been received,
:     the Receive returns return_code=CM_OK (as opposed to
:     CM_DEALLOCATE_NORMAL when no map name) and remains in the
:     Receive state (as opposed to entering the Reset state when
:     no map name) at the same time it returns data_received=
:     CM_COMPLETE_DATA_RECEIVED.

This solution requires no change to the state table since
a deallocation indication can arrive at the LU later than
a logical record has been completely returned to the program
today due to the timing condition.  The change proposed above
merely says that if the LU has both pieces of information to
be reported to the program on a conversation that is associated
with a map name, the LU should hold the deallocation indication
(i.e., treating it like a late arrival) and report the
deallocation indication to the program on a subsequent Receive
call.  Between the two Receive calls, the program has a chance
to issue an Extract_Map_Name call.

Regards,
Chung-Huy Chen

PS: The Internet Mailer-D complained about Colin Dancer's new
    address.  We are still working on solving this problem.
    In the meantime, if you have successfully contacted him
    through the Internet since the December CIW last year,
    please drop me a note at [email-masked].  Thanks.